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I. IHTRODOCTIOS 



A. GENERAL OVERVIEW 

The information contained in this section was obtained 
from a series of reference documents produced by both Naval 
Supply Systems Ccmmand (NAVSUP* and Fleet Material Support 
Office (FMSO) and is included as background [Refs. 1,2,3 ]. 

The Stock Point Logistics Integrated Communications 
Environment (SPLICE) project is being developed to augment 
the existing Navy stock Point and Inventory Control Point 
ADP facilities that support the Jniform Automated Data 
Processing System-Stock Points (0ADP5-SP) . 

Presently, there are twenty new applications systems in 
various stages of development which will require a consider- 
able amount of interactive processing and telecommunications 
support. The current OADPS-SP hardware is a Burroughs 
Medium Size (B-3 500/3700/47 00/'4 800) System, which will not 
be able to support these requirements without a total rede- 
sign effort and possible mainframe replacement. To support 
the interactive and telecommunications capabilities 
required, individual project managers for the new applica- 
tions systems development will be utilizing a variety of 
minicomputers. These systems will all be implemented within 
the next four to five years according to projected 
sch edules. 

The development of SPLICE will iave two major impacts. 
It will meet the increased need for the use of CRT display 
terminals to interact with application logic and retrieve 
information from the system data base and it will also 
address the need for a standard teleprocessing hardware and 
software environment to support the many new projects that 
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will impac* all Navy UADP5-SP sitss. This staadardization 

will provide major economic benaCits in tha stages of 
design, development, operation and maintenance which will 
occur at approximately sixty geographically distributed 
sites, each having a different mix of application and 
terminal requirements. 

At this time, the SPLICE processors are planned to be 
co-located with the hosr Burroughs Medium System at each 
Stock Point (SP) activity and with the Burroughs and Univac 
systems at the Inventory Control Points (ICP's) . The SPLICE 
project proposes a distinct division of processing responsi- 
biliries called a ''foreground/background" concept. The 
SPLICE foreground, utilizing a standard minicomputer hard- 
ware and software set, will serve as a fronr-end processor 
for the Burroughs system via a Local Area Network (LAN) 
interface and will handle communication lines as well as 
support the interactive operations. This interactive trans- 
action processing support will be accomplished using the 
Terminal Applications Processing System (TAPS) data ccmmuni- 
cacion terminal management for both on-line and host 
processing terminals, and networking communication logic for 
Navy-wide distributed and satellite activity capability. On 
the host background processor (initially the Burroughs 
Medium System computers at each Stocx Point), the functions 
performed will include large volume updating of master 
files, creating hard copy reports and other functions not 
requiring interactive immediate response access. 

B. THESIS OBJECTIVES 

A portion of the SPLECE project was initiated at the 
Naval Postgraduate School, Monterey, California, at the 
request of FMSO, to develop and design suggested 
alternatives for SPLICE Local Area Networks. The purpose of 
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this thesis is to examine these alternate design specifica- 
tions and indicate what integration oonsiderations have been 
met and those areas that remain to be addressed among nhe 
various functional modules that have been developed in 
support of both intranetwork communications occurring within 
the LIN itself and internetwork comn unications between the 
LAN and the Defense Data Network (See Appendix S ). 



C. BACKGBOOND 

The implementation of SPLICE as proposed by NAVSUP 
reflects a tightly coupled architecture which utilizes a 
centralized "complex manager" concept. The complex manager 
performs all required coordination between the SPLICE system 
components, or functions. Eight of these software functions 
have beer, identified for development to support the SPLICE 
concept. These functions are Terminal Management, Terminal 
Applications, Data Set Management, Peripheral Management, 
Batch Applications, Complex Management, Stogk Point 
Front-End Processor Support and Stock Point Host-Resident 
Support. The first six functions will provide an applica-r 
tion independent environment for LAN processing, while the 
last two support the Stock Point Host interface for 
foreground/background communication. It should be noted here 
that the entire SPLICE design, as outlined in the SPLICE 
System Specifications [Ref. 2] and the SPLICE Software 
Design [Ref. 1] revolves around a predetermined desire to 
use the Terminal Applications Processing System (TAPS), 
which is currently in existence at various Navy Stock 
Points. TAPS is designed to provide Communications 
Management (CM) , Application Management (AM) and Data 
Management (DM) capabilities necessary for the Navy applica- 
tion systems to support on-line interactive query and update 
processing on the foreground complex. 
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The alternate SPLICE functional design approach taken 
here at the Naval Postgraduate School is directed towards 
designing the logical or virtual Local Area Network first, 
thus ensuring that functional requirements are satisfied 
[Ref. 4], This is accomplished through the development of 
Functional Modules and their characteristics and the deter- 
mination of communication protocols necessary to support 
them. The need for a complex manager is eliminated by 
providing the necessary control structures for a fully 
distributed LAN. The ability to move a functional module 
from one functional node to another will provide higher 
system availability than in the case of fixed assignment of 
functional modules to physical nodes. Through the proper 
distribution of functional resources across the nodes of the 
LAN, the failure of any one node would be transparent to the 
user and a higher degree of overall LAN reliability is 
provided than would exist with the use of a centralized 
complex manager. 
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II, LOCAL AREA NE TWO RK AND FONCTIDNAL M ODO LE OVERVIEW 

A. LOCAL AREA NETWORK (LAN) DESIGN 

A LAN has been define! as a data communication network, 
typically a packet comma nication network, limited in 
geographical scope [Ref. 5], 

Basically, local area networks provide for the intercon- 
nection of data processing and computing devices located 
within a limited geographical area. They are primarily 
aimed at providing a communications means for processes 
resident in the multiple hosts which connect to the network. 
LANs have been installed and implemented in various forms 
for a multitude of functions, and have experienced varying 
degrees of success [Refs. 5,7], 

Due to the future increases of computing devices at the 
Navy's Supply Points ana Inventory Control Points, 
networking of the devices within the local area offers the 
potential to efficiently share available resources. A local 
network structure capable of providing compatible intercon- 
nection of various terminals, data processing devices, word 
processors, gateways to other computer networks and of 
virtually any type of digital communication device, can 
provide an extremely flexible and highly reliable environ- 
ment for SPLICE configurations. 

A major advantage pf local area networks in general is 
that, once implemented, the local area network can support 
practically any type of system transition. Another signifi- 
cant aspect of a well-designed local network is that it can 
support a long-term, vendor-independent transition strategy. 
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Local networks do create certain problems that must be 
considered, however. Provisions must be made for speed 
matching between the local area network and the long-haul 
network. In this particular instance, this matching must 
occur between the SPLICE LiN and the DDN. It can reasonably 
be presumed that the LiN will have a much higher dara rate 
than the DDN. Thus, when a large number of packets are sent 
into the LAN to reach their ultimate destination through rhe 
DDN, packets may arrive at the gateway much faster than the 
gateway is able to pass them to the DDN. A mechanism is 
required to prevent the gateway from exhausting its buffer 
space. Additionally, the virtual circuit protocol in the LAN 
must be compatible with that of the DDN to allow for easy 
translation. 

One of the basic elements which one must consider when 
dealing with LAN design is the topology method used for 
network interconnection. This issue is an important one in 
the performance of the LiN and is presented more fully in 
the following section, 

B. BOS TOPOLOGY 

Network topology is the arrangement of digital devices, 
called nodes, relative to the interconnecting media. In the 
recent evolution of local computer networks, several topolo- 
gies have emerged. The SPLICE reliability requirements (as 
outlined in the Functional Description) preclude a system in 
which the network can be made inoperative by a single compo- 
nent failure. SPLICE configurations will also be subject to 
changes over time. Thus, SPLICE requires a topology which 
provides high resilience to single component failure while 
also allowing for system growth and reconfiguration. For 
these reasons, a bus architecture was chosen [Ref. 8]. 
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The global bus configuration is an interconnection 
scaeme in which all network computers or nodes are party to 
a single communications channel which is used in a message 
or packet switching mode. The channel may be a single wire 
pair or coaxial cable or even a multi-wire conduit. All 
node-to-node communications takes place over this shared 
channel. The channel operates in a broadcast multiple access 
mode, similar to that of an internal computer bus, where a 
transmission by any of tie nodes can be received by all of 
the remaining nodes in the network. Access to the channel is 
controlled by any of a number of different time multiplexing 
schemes. The global bus topology for local networks has 
several inherent advantages over other topologies, including 
low cost and ease of incremental network expansion. 
Throughput and message delay characteristics are highly 
dependent on the access control protocol used 'Ref. 9]. In 
this shared channel computer communication network, only one 
message can be transmitted on the cns nr. el at a time. Thus, 
it must be determined who can transmit at any given time via 
some distributed control mechanism. Additionally, an 
addressing mechanism is required to aid in data flow 
patterns. As will be seen in a later diagram (Figure 2.1 ), 
the logical design of the SPLICE LAM provides two types of 
buses: a data bus which will transfer the actual applica- 
tions messages and a control bus whrch wall carry 
administrative traffic (such as resource allocation and 
error messages). Few local networks available from vendors, 
however, provide separate data and control buses due to the 
additional cost and hardware required. Thus, physical imple- 
mentaticr. of this design will utilize one bus [Bef. h ]. 
This physical configuration can be seen in Figure 2.2 . 
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C. FUHCTIOHAL HODOLES 



A functional module is defined as one which provides a 
generalized function for nany applications. As opposed to 
having many sets of applications modules, there will exist 
one set cf functional modal es which can provide services for 
many applications. This design methodology was chosen to 
save time and money in system development and implemenration 
[Ref. 10]. Since many functions are common to various 
applications, a great deal of duplicate work in the areas of 
system analysis, design, programming, coding, testing and 
maintenance will result if applications modules are designed 
and implemented for each and every application. The func- 
tional module approach will eliminate this redundancy and 
alsc result in the better utilization of computer resources, 
primarily memory and file storage space. This last benefit 
is due to the fact that the major differences in applica- 
tions usually exist in the input and output formats and 
applications parameters; they are not normally in the basic 
operations of editing data, maintaining files and generating 
displays and reports. 

In the Postgraduate School design of the LAN, the gener- 
alized approach using functional modules is emphasized. Ten 
functional modules have oeen identified to date, although 
not all have been completely designed. They are listed in 
Table I . 

These modules are divided into two basic categories: 
operating functions such as the transaction processing 
modules, and support functions which ure those that exist to 
ma^e effective use of the processing modules and the entire 
LAN. Figure 2.1 illustrates the logical connections as envi- 
sioned in the SPLICE LAN design. The actual configuration 
is envisioned as being similar to that shown in Figure 2.2 . 
It illustrates a LAN configuration utilizing three 
minicomputers in addition to the mainframes at SPLICE sites. 
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TABLE I 

Functional Molulas 



Local Communications 
National Communications 
Front-End Processing 
Terminal Mana cement 
Data Base Management 
Session Services 
Perioheral Management 
Security 

Recovery Management 
Network Management 



Following is an overview of rhe modules and the basic 
services they perform. The major modules and rheir rela- 
tionship to other modules will be discussed in detail in 
Chapters III and IV. 

I* Local Co mmunicarioa s 

- Bus arbitration (traffic management) 

Message transmission and reception including buffer 
management 

- Message control (error defection, correction and ackncwl- 
edg emenr) 

- Administration (including message accounting, handling of 
lost or misdirected messages and LAN shutdown) 

2. Nstion^l Communicar ions 

- Z on version of the Defense Data Network protocols to LAN 
protocols and the reverse 

- Message assembly and disassembly 
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Local Natwork Logical Connections. 
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Front-En d P ro ces sin o 

- Terminal and ccmmunicatiD n line buffering 

- Code Conversion 

- Byte/word assembly and disassembly 

- Control message processing 

- Authentication 

4. T ermina l Management 

- Message editing 

- Screen management 

- Virtual terminal operations 

5* D at a Base Manage ment 

- File creation and updating 

- 3uery processing and data retrieval 

- Data dictionary creation and maintenance 

- File catalog creation and maintenance 

6 • S ess ion Ser vice s 

- Establish and maintain local and remote sessions: 



a. Within the LAN (SPLICE minicomputer processes) 

b. With local host (s) (the mainframe processes) 

c. With remote host(s) (also mainframe processes) 

- Provide logical and physical network addresses based on 
value of a Services Reguest Code 

- Access control 



• Periph e r al Management 

- Management of Unit Record Input/Dutpur (to include reading 
cards, printing lines, and spooling files for input and 
outpur) 

- Dptical Character Recognition or Mark Sense Eguipmenr 
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8 . Security 

- Provide positive user identification via passwords 

- Control authorization verification 

- Provide for reconstruction of critical data 

- Provide auditing facilities 

5 • Re cover y Management 

- Receive and react to notification of transmission errors 
(existence of an error condition) 

- Maintain LAN copy of Network Directory and updare it when 
physical address changes occur 

- Notify the Network Management module and all funcrional 
modules and processors within the LAN of changes in LAN 
status. 

10. Network Ma n age ment 

- Perform monitoring and measuring of LAN performance 

- Svaluate network performance and identify down or failing 
com ponents 

- Monitor and control LAN interface to long-haul network 
(DDN) 

Regulate flow of packers between networks and perform 
ether tasks to support this flow 

Provide local failure notification to nodes and hosts 
outside of LAN and provide LAN with information about 
outside nodes and hosts 

Provide accounting capabilities (i.e., resource 
utilization) 
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III. COBM UNI CAII ONS FONCTIOMAL MOD ULES 



A, NATIONAL COM MON ICATION (NC) MODULE 

It is a common user raguirement that a single terminal 
anl access port should be able access any computing 

resource that the user may desire -- even if the resource is 
on another data network. Based on this requirement, there 
arises a user need to have data networks connected together. 
Although from user viewpoints the requirement for intercon.- 
nection is independent of the network technology, this is 
not true from the implementation viewpoints. There are some 
considerable complications in connecting networks of rela- 
tively different technologies. These interconnections can be 
viewed primarily in terms of interfaces and network services 
[Ref, 11 ], 

These can both be divided on the basis of the character- 
istics they possess - those of datagram or those of virtual 
circuit. It is important to distinguish datagram and 

virtual circuit services from datagram and victual circuit 
interfaces. 

• Da ta g ra m /Virtua l T i rc ui t 

A datagram interface allows the subscriber to enter 
packets into the network independent of any other packets 
which have been or will be entered. Each packet is handled 
separately by the network. A virtual circuit interface 
requires an exchange of control information between the 
subscriber and the network for the purpose of setting up 
address translation tables, setting up routes or preallo- 
cating resources, before any data packets are carried to the 
destination. Thus, an end-to-end logic circuit must be 
established. 
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k datagram servics is ons in which each packer is 
accepted and treated by the network independently of ail 
others. Sequenced delivery is not guaranteed. In fact, there 
is no guarantee that all datagrams will be delivered. Since 
packets may be independently routed over alternate network 
paths, duplicate copies of datagrams might be delivered. A 
virrual circuit service tries to guarantee the sequenced 
delivery of the packets associated with the same virtual 
circuit. It typically provides the host with advice from the 
network on flow control per virtual circuit as opposed to 
the packet-by-packet acceptance or rejection typical of a 
datagram service. Any duplicate packets produced are 

filtered by the destination packet switch before delivery zo 
the subscriber. 



2. O perati o n 



The NS module of the local network provides the 
interface between the LAN and rhe DDN. In the NC module, 
booh sides of this interface will provide a virtual circuit 
service [Ref. 4]. Packets will be transmitted on the DDN 
backbone, while fragments will be transmitted on the LAN. It 
will be the responsibility of the NS module to provide the 
interface between the DDN and each LAN. This will require 
that a conversion be provided between the LAN protocol and 
TCP, the protocol utiliced by the DDN. (See Appendix C for 
specifics on TCP.) To avoid coniecting all functional 
modules and nodes directly to the DDN, a gateway will be 
used. The fundamental role of a gateway is to terminate the 
internal protocols of each network to which it is attached 



while, at the same time, 
which data from one networc 



provide a common ground across 
can pass into another [Ref. 5]. 
The NC module will function as the gateway and contain both 
the TCP and LAN protocols. 
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Messages from the DDN in the form of packets accumu- 
late at the NC. The message or fragment (if the NC has found 
it necessary to perform fragmentation on the incoming 
message) is then sent to the destination module over the 
LAN. The destination module's logical address and its phys- 
ical address would have been recorded in the message (see 
Session Services Module) at the originating LAN [Ref. 10]. 

The task of broadcasting physical address changes to 
“he various LANs must be accomplished and it is currently 
envisioned that the Nerwork Management Module located at 
FMSO will handle this. Additionally, each LAN must keep a 
copy of the network directory and make all necessary changes 
to the network physical addresses as they occur. This will 
be done by the resident Recovery Management Module [Ref. 4]. 

Physically, the NC resides in the Front-Snd 
Processor. It will perform host to host flow concrol but nor 
alternate routing. Messages will be sent no the nearest 
Packet Switching Node (PSN) of the DDN on a FIFO basis. 
Since the LAN speed will feasibly be greater than than of 
the DDN, the NC buffer could easily fill to capacity. One 
method of handling this potential problem is to only permit 
a single message to be unacknowledged at a time [Ref. 4]. 
In addition, it will necessary to reserve buffer space equal 
to the maximum size message fragment that could be received. 
By utilizing these restrictions, message handling will be 
done in a uniform fashion both intra LAN and inter LAN. 
Certain problems could result from the first restriction, 
however, and these will be discussed in the last chapter. 

3. TCP 

As previously mentioned, TCP is the primary 
host-to-host protocol in the DDN. An overall description of 
TCP can be found in Appendix C; however, the key 
characteristics are reiterated here: 

- Host-to-Host Protocol 
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- Resident in the ISO Transport Layer 

- Messages delivered in sequence 

- Logical full-duplex connections 

- Sequence number assigned to each octet 

- Message sequencing and acknowledgements controlled by rime 
outs 

- Connection name used to refer to connections after connec- 
tion is established. 

- Precedence and security of messages may be esrablished by 
use rs 

- Window oriented flow control 

- Destination TCP reassembles message segments 

- Mandatory that ac knowleig emenrs be sent 

Only those aspects of the PC? which are necessary to 
convert messages from LAN to DON format and vice versa will 
be implemented in the NC. The TCP commands which will be 
implemented in the NC are as follows: 

* OPEN 

- Active: Begin procedure to synchronize connection 

- Passive: Listen for an incoming signal 

(Respective modules will be notified by their local and 
remote NCs when a connection has been made.) 

* SEND 

- send data contained in the indicated user buffer on the 
connection indicated 

* RECEIVE 

- allocate a receiving buffer associated with the specified 
connection 

* CLOSE 

- close the specified connection 

(Respective modules will be notified by local and remote NCs 
that the connection is closed.) 

* STATUS 

- obtain status of connection 
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(This command is not always implemsntad; howevar, ii would 
be to the advantage of the SPLICE network to utilize it.) 

* iBOET 

- causes all pending SENDs and RECEIVES to be aborted. k 
RESET message is sent to the remote TCP. Respective modules 
are notified by their local and remote NCs that the connec- 
tion has been aborted. 

It should be mentioned here that the activity of the 
TCP can be characterized as responding to events. The events 
mentioned above fall into the category of user calls. 
Processing is dene by the TCP in response to each of the 
events that occur. In many cases, the processing required 
will depend on the state of the connection. 

4 . N etw ork Laye rs 



For sending and receiving massages on the DDN, all 



seven network layers as 


de fined 


in the Reference 


Model 


of 


Open Systems Interconnection 


(OSI) 


proposed 


by t 


h = 


International Standards 


Or g anizat 


ion (ISO) 


[Ref. 12] 


will 


be 


used. See Table II 


The TCP 


format 


[Ref. 23] 


will 


be 



provided to the DDN by the NC module whenever communication 
on the DDN is necessary. 

5 • Addressing 

The TCP uses port identifiers in its header to iden- 
tify the separate data streams that the TCP may handle. 
Since port identifiers are selected independently by each 
operating system, TCP, or jser, they might not be unique to 
each TCP. To provide for unique addressing at each TCP, an 
internet address identifying the TCP is concatenated with a 
port identifier to create a socket which will be unique 
throughout all networks connected together [Ref. 10]. The 
TCPs are free to associate ports with processes in any 
manner ~hey choose; however, several basic concepxs are 
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necessary. It is envisioned that processes may "own" ports 
and that rhsy can only iaitiare coanecticns on the ports 
that they own. A connection is specified in the OPEN call 
by the local port and foreign (destination end) socket argu- 
ments. After the connection has been opened, the TCP 
supplies a local connection name by which the user refers to 
the connection in subsequent calls 'Ref. 23]. 

In the SPLICE LAN, the port identifier will corre- 
spond to the logical address of a functional module. The 
network address corresponds to that of a physical processor 
in which the module resides. This will allow for the flexi- 
bility and mobility of modules, since logical addresses do 
not change, whereas physical addresses are subject to 
change. Both types of addresses will be necessary to access 
a particular functional module in the SPLICE network. 
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B. LOCAL COMMON ICITIONS (LC) MODULE 



The LC module will also uss a virtual cirouit service. 
It will be possible to set up a virtual circui- between any 
two modules. The circuit would be implemented by creating 
tables rn the Session Services module at both the receiving 
and sending ends of the connection [Ref. 10]. The virtual 
circuit can be established between two functional modules 
residing in the SPLICE mi nicompurecs and also between a 
functional module residing in a SPLICE minicomputer and a 
functional module residing in a main frame. 

1 • N etw ork Laye rs 

The TCP protocol, as it is currently specified, is 
more complex than necessary for use in a local area network 
such as SPLICE. In addition, measurements of the TCP 
[Ref. 23] indicate that it has very poor throughput compared 
tc a high speed (1 3 Mbirs/se c) bus such as the one proposed 
for the SPLICE local area network, and thus will not provide 
optimal local communication performance. If the entire TCP 
were included in LAN communications, many extra functions 
nor needed would be unnecessarily implsmenred. Thus, the 
besr approach seems to be to utilize a subset of rhe DDN 
virtual circuit protocol, waich is as close to TCP as 
possible, but which specifies only those portions needed by 
the LAN. In rhis manner, translation between the rwo proro- 
cols is simplified and protocol compatibility is provided 
without the necessity of designing trfo protocols [Ref. 5]. 

Overall, a much simpler format, as shown in Table 
III, will be used for intra Lan communication than that of 
the entire ISO model. The LAN will not require the detailed 
services normally provided by the Transport and Network 
Layers [Ref* '♦]• The Presentation Layer functions will be 
implemented in the Terminal Management module. It will 
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accept data from the application process and convert it to 
the designed LAN standard format. It will also accept LAN 
formatted messages and convert them to the appropriate 
application process format. A terminal user would be 
considered an "application process" in this conversion 
activit y. 

The end-to-end virtual circuit connections (the 
logical commun ication linkage between two functional 
modules) and the fragmentation of complete messages can be 
implemented in each of the functional modules, as opposed to 
having them handled by a Transport Layer [Ref. 4]. In this 
manner, a subset of the DDN virtual circuit protocol (TCP) 
would be used, as previously descrioed, and the need for a 
complete Transport Layer would be eliminated. 
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A ddress ! ng 

To enable impls mentation of the architecture which 
has been described, it will require that logical addresses 
be assigned to the functional nodules which will be 
contained within the SPLI3E minicomputers and to the func- 
tional modules which currently exist in the S? and ICP main 
frames. This last assignment will require the identification 
of programs or packages in the main framesthat make up a 
functional module. The identification of resources is a 
central issue in the development of distributed systems in 
order to provide location independence and the possibility 
of having multiple copies of the same functionally named 
resource within the LAN [Ref. 10]. This location indepen- 
dence should permit end users and applications programs the 
ability to access and manipulate data regardless of whether 
it resides locally or at another node on the LAN or at any 
remote node in the SPLICE network. To support this location 
transparency, it will be necessary to create and maintain a 
table which will provide tie physical address of a hardware 
unit when the logical address is given. This table and all 
necessary maintainance functions associated with it will be 
the responsibility of Session Services [Sef. 10]. Although 
a table concept was originally developed for a ring network 
structure [Ref. 13] it can be simulated under other network 
architectures, such as Ethernet, which also uses a bus 
structure [Ref. 10]. 

3 • M es sage Forma ts 

LAN message formats have been designed by many 
authors. The basic structure provided here was designed in a 
previous thesis [Ref. 8], however, additional features have 
been included to incorporate other functions performed by 
the network [Ref. 4]. If other functions are required, they 
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can be included at a later date in much the same manner. 
When a module requires an acknowledqement, the acknowledge- 
ment will be piggybacked onto a data message if data is 
ready to send to the module. If there is no data to 
transmit, an ordinary ackn owladgemea t message will be used. 
Requirements for control must be incorporated into this 
method. These will allow for priority message notification 
as well as distinguish between new messages and acknowledged 
messages. It is planned that messages will be transmitted in 
one continuous stream of bits * Ref . ^ Although this will 

simplify the communications protocol, buffer space must be 
reserved for the maximum size message. To handle long 
messages which could exceed the maximum buffer size of a 
functional module, fragmentation is used [Ref. 14]. A frag- 
ment is merely a part of a message. In this instance, 
identification numbers must be provided for both messages 
and for fragments. Following are illustrations of the intra 
LAN message formats and descriptions of the packet format 
fields. The data field length is allowed to vary. All other 
fields should be fixed length, however specific lengths for 
these fields can be determined after detailed network 
configurations and hardware specifications have been 
established [Ref. 8]. 

a. Flag 

The flag field is a bit pattern which signifies 
the beginning and ending of a message or message fragment. 
The beginning flag field is also used to synchronize the 
receiving processsor with the incoming bit stream. This 
pattern should be chosen such that its length is sufficient 
for positive identification and its distortion due to colli- 
sion with another transmitter’s flag is easily discernable 
by collision detection devices. The use of the flag sequence 
is data or control information that occurs between flags 
must be prevented through use of a bit stuffing mechanism. 
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Figure 3.1 LAN Message Format, 
b. Message Type 

This is a code indicating the type of message 
being transmitted. The major message types are as follows: 

- Normal Data 

- Priority Data 

- Ordinary Acknowledgement 

- Data with Piggybacked 4c knowledgsnen t 

- Reset LAN (resets comman icat ions after error condition) 

- Reset Message and Fragment Counts (resets counters to 
zero) 

- LAN shutdown 
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- others 

c. Date and Tiae 

This provides the day, aonth, year and 24-hour 
clock time of message transmission from sender. 

d. Destination Adiress 

This provides the logical and physical address 
ot the receiving module. It will inform rhe correct module 
to copy the rest of the bit stream and continue processing. 

e. Source Address 

This provides the logical and physical address 
of the sending module. It is reguired for proper addressing 
of acknowledgements and co mmun icatio ns control information 
which must be maintained. 

f. Number of Fragments 

This provides the number of fragments contained 
in a message. It is used primarily for message sequencing 
and for acknowledgement control and also by the receiving 
module for allocating buffer space. 

g. Message Number 

This is the sequential number assigned no each 
rransmirred message. If the message being sent is an 
acknowledgement, the numoer of the message being acknowl- 
edged would be placed in this field. This number is reset to 
zero on a periodic basis. Each modale will be responsible 
for setting, resetting and incrementing this count. In this 
meaner, the receiver will always know which message it 
should next receive and the sender will know which message 
number should next be acknowledged by the receiver. 
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h. Fragment Number 



This is a sequential number which is assigned to 
each fragment that belongs to a message. This number will be 
reset to zero by the sender as soon as the first fragment of 
a new message is ready to be transmitted. Each module is 
responsible for setting, resetting and incrementing this 
count. In this manner, the receiver will always know which 
fragment number it should next receive. (The message number 
will be increased after all fragments have been received.) 
The sender will know which fragment number should be next 
acknowledged by the receiver. The first fragment will be 
numbered zero. 

i. ickn owledgemeat Message Number 

This provides the message number that is being 
acknowledged. 

j. Acknowledgement Fragment Number 

This provides the fragment number that is being 
acknowledged. 

k. Data Length 

This field provides the number of bytes in the 
data portion of a message or message fragment. If no data is 
being sent, this field can have a value of zero. 

l. Services Request Code 

This code will indicate which service is being 
requested by a process. {«• g- retrieve record, update 
record, etc.) 
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Data 



The data field contains the information *o be 
delivered by the network. All other portions of the message 
header are stripped from tie message when it arrives at the 
receiving module. 

n. Error Check 



This field contains the Cyclic Redundancy Code 
(CRC) which is a checksum computed by the sender. If an 
error is detected by the receiver, tie fragment is discarded 
by "he receiver and will nat be acknowledged. A match indi- 
cates that there are no errors and the message will be 
accepted by the receiver and acknowledged. If sender does 
not receive an acknowledgement after an appropriate amount 
of time, it will assume lon-receipt and retransmit. If the 
second attempt at transmission fails, the Recovery 
Management module will be notified of an error condition. 



It should be noted that the Message Number and 
Fragment Number fields will be used for data messages and 
for non-piggy backed acknowledgement messages. The 

Acknowledgement Message Number and the Acknowledgement 
Fragment Number fields are only used when the acknowledge- 
ment is piggybacked onto the data being sent. The Data 
Length, Services Request lode and Data fields are only used 
whan data is actually being transmitted in a message. 
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IV. HAMGEMENT AND CONTROL FONCTION^ MODOLES 



A. SESSION SERVICES (SS) BODDLE 

The SS module provides the overall controlliug mechanism 
among the clients of the LAN functioial resources, i.e. the 
terminal user and other functional resources themselves. 
Although the original design of Session Services [Ref. 10] 
malcss a distinction between Controlling SS and 
Non-controlling SS, for tae sake of simplicity and to avoid 
confusion, this thesis will consider Session Services as one 
entity containing all described characteristics. Regardless 
of whether a process is based on an interactive application 
or on an interactive session (via a LAN user's issuance of 
query language transactions), there nust exist a controlling 
service to communicate aid control the requirements of the 
user process (es) between itself and the functional resources 
of the LAN. In order to establish communication between the 
controlling mechanism, the user and the functional modules, 
a simple reque st- accept message transfer needs to be 
performed [Ref. 10]. This service request code in a 
message, similar to a usee request task, is used by SS to 
obtain *he logical and physical addresses of the functional 
module(s) which will perform the requesred service. An 
acknowledgement, indicating either acceptance or denial of 
session support, would be sent to tie requesting SS module. 
After this series of events has been established, the user's 
process can communicate freely throigh SS without the need 
to reconstruct another session service. References to 
currently supported user sessions would be maintained in a 
table and could be used to identify the validity of client 
access for service by the functional resource. SS will 
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invoke the appropriate functional aoiule which then accesses 
the user message in the Terminal Management buffer. The 
moiule returns the required data after interpreting the 
instructions in the user message. It is the responsibility 
of Terminal Management to present the data provided by the 
functional module in the format needed by the user [ Sef . 4], 
This enrire process involves all the ISO layers (as illus- 
trated in Figure III ) required to support intra LAN 
communications. 

If certain requests for service from a user process 
require coordination and control of multiple LAN functional 
resources. Session Services will ensure that the request is 
appropriately broken down into its respective component 
service requests and that they are performed in the correct 
order. Basically, SS operates through Terminal Management. 
This situation results from the fact that user process 
messages reside in Terminal Management during a session and 
ir is the responsibility of Terminal Management to keep the 
user informed of all progress associated with the processing 
of his request [Ref- 10]- SS Issues the various messages to 
the functional modules in support of this request. 

B. TEE MI UAL MANAGEMENT (TM) MODULE 

The purpose of the TM module is to provide LAN users 
with the facilities for communicating simultaneously with a 
large number of processes spread out among various systems. 
A terminal user might need to communicate with the LAN or 
with other local area networks (other Stock Points) through 
the DDN [Ref. 10]- Since the set of functional modules in 
this design approach each provide the same basic service, 
the major place where applications are differentiated is on 
the terminal screen formats. 
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Terminal handling has always bssi somewhat tf a orcblem, 
since, while terminals exhibit rather similar characteris- 
tics, they can differ in very significant ways. In a network 
architecture, the problem is additionally compounded. Each 
host musT support all n kinds of terminals supported by each 
of rhe m hosts cn the network. Thus each host must poten- 
tially be able to support m x n terminals to permit any user 
to connect to it. As can easily be seen, this is fairly 
impractical. 

Terminal-oriented protocols are designed to reduce this 
"m X n" problem to a manageable size by establishing conven- 
tions for handling all the zerminals on the network 
[Ref. 15]. One such approach to a terminal protocol defines 
a network virtual terminal (NVT) [See. 16]. In this method, 
the source terminal side of a connection maps the output of 
its terminal into the JIVT format for transmission through 
the network. At the destination terminal, the ;iVT format is 
mapped into its local format for presentation. The user 
ends, as defined above, could be processes as well as phys- 
ical terminals. This approach has tie advantage of avoiding 
the delays and efficiencies of attempting to synchronously 
share a data structure across a network. 

The NVT has several shortcomings, however, which must be 
considered [Ref. 15]. The introduction of new terminal 
commands or primitives without modifying the protocol means 
that each new terminal command will require a minimum of six 
octets (octet = 8 bits) to be represented. Because the 
protocol is stream-oriented, every octet of the data stream 
must be scanned to find control sequences. Secondly, for a 
virtual terminal protocol (VT?| to be successfully used in a 
general environment, the virtual terminal must be very well 
defined. Otherwise, programs that use the terminal in more 
sophisticated applications such as displaying and updating 
fields on a CRT will not be able to format their output 
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deterministically without considerable knowledge of the 
physical terminal being used [Ref. 15]. Thera is also the 
possibility that not all physical terminals may be able to 
service all virtual functions. Additionally, for a VTP to 
be generally applicable, it must restrict itself to terminal 
funct ions. 

European investigations into virtual terminal protocols 
have made two major contributions; (1) a well-defined 
virtual terminal and (2) the development of a model for 
attentions or interrupts [Ref. 17]. The VTP defines an 
basic framework for the virrual terminal, and classes of 
virtual terminals are defined that correspond to the classes 
of real terminals available (e.g., scroll mode, paged, data 
entry, etc.). Each class uses the basic model and adds to it 
the facilities and structures required. Thus, the use of 
terminal class avoids requiring tnat all implementations 
support the most sophisticated terminal functions and allows 
the characteristics of a virtual terminal to more closely 
resemble the real terminal being used [Ref. 17]. The 
European designs also provide commands for one side (virtual 
terminal) to request of the other what options and what 
range of parameters it supports and for the requested side 
to report what it can support. 

There may be some limitations imposed on the choice of a 
virtual protocol, however, as it is currently planned for 
the DON to use an ARPANET Telnet NVT feature [Ref. 22]. In 
this case, the NVT protocol will be probably needed in the 
TM module to enable commuaication with remote processes over 
the DDN. A Terminal Management generic module has been 
proposed [Ref. 18] which attempts to provide a methodology 
for utilizing a VTP other than NVT and still maintain 
compatibility with the DDN protocol. It is felt that this 
proposal should be further examined in terms of its 
suitability for the SPLICE local network. 
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C. DATA BASE HANAGEMENI (DBM) MODOLE 

Although the LAN lasigu provides for distributed 
control, it does not provide for tie total distribution of 
data bases within the LAN. There is, however, distribution 
between the interactive Data 3ase Management System (DBMS) 
in the SPLICE minicomputer and the Burroughs mainframe 
batch-oriented DBMS [Ref. 4], Data bases are, of course, 
distributed over the entire SPLICE network. The data base 
functions, however, are centralized within each LAN 
[Ref. 10]. This will enable the local network to maintain 
the necessary control and integrity of files, as the 
catalog, data dictionary and indices will be centralized. 

As distributed processing systems continue to grow, 
database management systems will have to undergo changes to 
be responsive to the special requirements of the distributed 
environment. This will be most evident in the situation of 
the local area network [Ref. 19]. Changes will be needed 
both in the service provided by database management systems 
and in the service implementation - the way it is packaged 
and delivered. System resources cannot be dedicated to 
single functional modules; for a variety of reasons, 
including the need to utilize common information, they must 
be shared. Rothnie and others [Ref. 20] believe that the 
type of architecture provided by 30D-1 is appropriate for 
activities requiring access to a single pool of information 
distributed over a wide geographical area. It will permit 
decentralized processing for reasons of performance, reli- 
ability and flexibility of function, and was designed to 
manage data bases whose storage is distributed over a 
network of computers. 

Lowenthal [Ref. 19] introduces the concept of a file 
server. This is a special purpose software module that, as a 
minimum, would coordinate concurrent access to a given file 
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from multiple requestors. It ran ilso support file sorting, 
catalog management and index saarchiag. In a DBMS, the fils 
server will handle the entire database as well as files. 
With adequate fixed disk storage for highly active files and 
moveable disk storage for less active files, it should be 
capable of supporting foreground queries and file 

maintenance requests. 

Closely relating to this concept is that of the backend 
database management system as discussed by Maryanski 
[Ref. 21]. This system was originally proposed as a solu- 
tion to the problems of overloaded data processing 

installations. Database management functions are offloaded 
from the existing mainframe to an attached ainicompurer. 
Basically, database requests are presented to the DBMS after 
they originate in an applications program and are trans- 
mitted through the interface routines. When the database 
request has been completed, the resulting data and status 
information are returned to the backend interface which 
initiates transmission of the results to the host. This 
method does have the advantage of freeing a substantial part 
of the processor's resources; however, it has a number of 
drawbacks as well. A major drawback is the performance 
penalty incurred by the introduction of the interface and 
communication software and the transmission time of the 
intercomputer link. Additionally, code conversion will be 
required for mapping character and integer data between 
different implementations. Both of the concepts presented 
are worthy of further investigation as to their applica- 
bility to the LAW design. A recommendation for a particular 
type of DBMS has not been made by provious studies [Refs, U 
,10 ], since it was felt that stronger emphasis should be 
placed on the capabilities of a vendor provided DBMS (i.e., 
integrity, recovery, dictionary, query language, data 
accessability , security, etc. I ratier than on the specific 
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moi€l selected. Although a complata dssign for the database 
functional module was not developed, a number of management 
tools (for providing organizational support) and some of the 
basic functions the DBMS should provide have been identified 
(Refs. 4 ,10 ] and these are briefly discussed below. 

A Data Sub-Language (DSL) consists of a Data Definition 
Language (DDL) for defining data objects (fields) and a Data 
Manipulation Language (DML) for the processing of data 
objects. As identified by the CODASTL group, the main func- 
tion of DDL is to describe the content and structure of the 
database schema and subschema. Althoagh all DBMS have a DDL, 
these can vary in the extent to which complex relationships 
can be expressed. The complexity and capabilities of the DDL 
should be worth careful consideration based on its applica- 
tion by Navy Stock Points and Inventory Control Points. The 
DMLs are used to transfer data to and from the database. 
They can be accessed by calls from a procedural language. 
The capabilities of the DML will directly affect the appli- 
cations programmer. Since the DDL and DML are closely 
related, the functionality of each generally determines the 
degree of responsibility of both the data base administrator 
and the applications programmer. 

Database Query Languages (DQLs) are generally interac- 
tive in nature. Often called "end-user facilities," DQL 
facilities provide direct interaction with the database 
schema and permit search strategies for data retrieval or 
updates by approved end users of the DBMS. With a user 
friendly DLQ, users can perform ad noc queries or can build 
user command files for repetitive data entry, retrieval and 
validation. A fully implemented and varied DQL will greatly 
support the current and future information requirements 
needed by the Navy Supply System. 
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Database utilities cover a multitude of areas, from 
password security to image management software and darabase 
tuning utilities. Additional database software for text and 
graphic displays, audit trail utilities, database develop- 
ment aids, database reloading and reorganizing aids and 
database sizing and responsiveness aids are also available. 
These could prcve extremely useful in support of LAN 
requirements. 

Data Dictionaries/Directories (DD/D) are vital in a 
distributed data environment and they may be implemented in 
a variety of ways. A data dictionary is used to identify and 
define the data elements oontained in the database, and any 
relationships that may exist between these data elements. It 
indicates where data resides geographically and what data 
are replicated. It should tell who owns the data, who are 
responsible for the accuracy of the data, who update data, 
and who is authorized to read the data. The data directory 
may refer to applications programs, input cr report docu- 
ments, or simply job streams, but generally it supports the 
use of data elements that were identified in the data 
dictionary. 

The DBM module must maintain the catalog of file names 
and status for files pertaining to the foreground applica- 
tions. This catalog should include filename, size, physical 
address of both file and index, location of backup copy, 
access restrictions and format. The module should also be 
able to retrieve records for display, change records, delete 
and insert records and print both records and entire files, 
'rfhen printing a record, the TM module will route the trans- 
action message to the DBM module. This module will locate 
and retrieve the record and send it to the Peripheral 
Management (?M) module for printing. If a user desires to 
print a file, the DBM module will have to open the file for 
the ?M module. The PM module will then access and spool the 
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file onto its own disk file. It ran then print the file 
without tying up the rest of the LkJf operations [Ref. 4]. 

Capabilities should exist to prevent data integrity 
problems when multiple processes read or update the same 
data. The system should also permic the use of high-level 
database user languages for data retrieval, report 
formatting and searching for and updating the data. 

Although the above suggestions do not cover every aspect, 
of a DBMS components and funrrions, they do describe the 
types of facilities and capabilities which must be consid- 
ered in providing a completely distributed processing system 
for the LAN. 






SIMCLOSIOHS MD RECOHSENDATIONS 



It is felt that the overall design of the LAN in terms 
of the functional modules presented provides a qualitative 
and useable design effort for a listributed Local Area 
Network. A number of issues still remain to be addressed, 
however, to insure that all functions have bean completel/ 
considered and developed. 

- Continued support of organizational needs is paramount in 
the design of any LAN. If LAN operability can be terminated 
by the failure of any single node (functional module), than 
the LAN has the potential to be highly unreliable. Some 
effort should be expended on providing dependability through 
a method for duplication of critical data and critical 
functions throughout the LAN. 

- More effort should be devoted to the development of the 
DBM module and the DBMS. Careful consideration of the inter- 
relationships between the Stock Points and the Inventory 
Control Points should be made in the selection of any DBMS 
to support long range organizational objectives. 

- Additional research should be performed in the areas of 

security and in the management of functional shared 
resources. The provision of security controls that are tamp- 
erproof may best be accomplished by designing them into the 
hardware. - Although the concept of having only one message 
outstanding at a time between a pair of functional modules 
on the LAN provides certain advantages (i . e. , reduced buffer 
size requirements), there can be a significant drawback as 
well. Since a monumental share of the communications will 
be occuring between the Front-End Processor and the Terminal 
Management and Session Services modules due to the physical 
connections envisioned (see Figure 2.2 ), it is quite 
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feasible that this restriction on window size for rhs 
various modules could create a backlog of messages for rhs 
bus. It IS recommended that additional study be done to 
determine whether or not it would be more efficient and 
productive to increase the suggested window size and allow 
more than one unacknowledged message to exist at a given 

- Backup and recovery are very important in support of 
the SPItICS requirement. Additional study should be performed 
in these areas and a working Recovery Management module 
should be developed to landle error detection within the 
LAN . 

A Security Management module should be developed after 
the appropriate appropriate risk analysis has been performed 
to provide for the important considerations of security and 
privacy needed in a distributed system. 

- A design for a Front-End Processor should be initi- 
ated. It is suggested that a programmable front-end 

processor would be more cost effective in communications 
control and would provide more flexible solutions to 

changing communications requirements. 

A menu for dialogues should be incorporated into 
Session Services to enable users to more easily employ 
distant databases, making inquiries, searching the data, 
generating reports, and, where desirable, updating and 
creating data. 

- A Peripheral Management module should be developed to 
meet the need for unit record input and output control. This 
functional module will enable users to print lines, have 
cards read and spool files for input and output. Thorough 
research should be done to determine what specific require- 
ments may be required to meet current and future needs of 
the Stock Points and Inventory Control Points, 
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- A simulation model stiould be designed to estimate the 
performance of the LAN as designed. Attention should be 
particularly focused towards response time and message 
transit time. 
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APPENDIX A 
ACRONYMS 


ACK 


Acknowledge men t 


AM 


Application Management 


ARP ANET 


Advanced Research Projects Agency 

Network 


B3N 


Bolt Baranek and Newman 


CHE 


Cyclical Redundancy Check 


cRr 


Cathode Ray Tube 


CM 


Communications Management 


DARPA 


Defense Advanced Research Projects 

Agency 


DBM 


Data Base Management 


DBMS 


Data Base Management System 


DD/D 


Data Dictionary/Directory 


DDL 


Data Definition Language 


DM 


Data Management 


DML 


Data Manipulation Language 


DOD 


Department of Defense 


DSL 


Data Sub-Language 


FD 


Functional Description 


FEP 


Front-end Processor 


FMSO 


Fleet Material Support Office 
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IMP 


Intarface Messaga Processor 


I? 


Internet Protocol 


IPLI 


Internet Private Line Interface 


LC 


Local S omnmnicati ons 


NAVSUP 


Navy Sipply Systems Command 


NC 


National Communications 


NM 


Network Management 


NVT 


Network Virtual Terminal 


PH 


Peripheral Management 


RM 


Recovery Management 


SM 


Security Management 


SP 


Stock Point 


SPLICE 


Stock Point Logistics Integrated 

Communications Environment 


SS 


System Specification 


TAC 


Terminal Access 


TAPS 


Terminal Application Processing System 


TCP 


Transmission Control Protocol 


UADPS-SP 


Uniform Automated Data Processing System 
- stock Point 


VTP 


Virtual Terminal Protocol 


WIN 


WWMCCS Intercomputer Network 


WWMCCS 


World Wide Military Command and Control 
System 
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APPENDIX B 

DEFENSE DATA NErWDRK I 

The following information is provided as a short summary 
of the Defense Data Network (DON) . The source document used 
is the D efe nse Data Ne|.w2EiS E£22£l,5. Eilll revised May 1982 
[Ref. 22]. 

A. GENERAL DESCRIPTION 

The DDN is designed to be a single integrated packet- 
switching data network whirh meets DOD data network 

requirements, both present and planned. The DDN takes full 
advantage of existing operational networks, such as the 
WWMCCS Intercomputer Network (SIN) and the Advanced Research 
Projects Agency Network (ARPANET), £or hardware, software, 
operations and maintenance procedures adaptation. Its design 
will be based primarily on ARPANET technology. 

To reduce development, maintenance and logistical 
support costs, it is planned to standardize components to 
the maximum extent possible. These components are switching 
nods hardware, switching node software, cryptographic 

devices, mini-TACs, host front-end devices, host interface 
devices and multiplexers. 

The switching node is a 3olt Baranek and Newman (BBN) 
C/30, which is a microprogrammed minicomputer that can 
include TEMPBST/HEMP protection. This is the most current 
generation of packet switching hardware using the Interface 
Message Processor (IMP) software. The C/30 is designed for 
unattended operation and requires no dedicated personnel. 
DDN will have 171 switching nodes located at approximately 
85 geographically distributed sites. These nodes will 
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reside on military facilities and are secure to a minimum 
level of SECRET. The DDN will contain a number of network 
Monitoring Centers (MCs) : a principle System MC, an alter- 

nate MC , regional MCs in the Pacific and in Europe, and MCs 
at each keyed community. The MSs monitor the network 
status, provide for fault isolation and diagnosis, support 
software maintenance in the nodes and mini-TACs, and 
maintain network elements information. 

The network is designed to minimize communications 
errors through the use of error detection and correction 
meohanisms. A Cyclical Redundancy Check (CRC) of 16 bits is 
associated with host messages on the access line and with 
packets on trunks to handle burst errors rhat typically 
occur. In addition, 16-bit checksums are provided on an 
end-to-end basis within the switch subnetwork and on a 
user-to-user basis via the Transmission Control Protocol 
(TT?) . The protection mechanisms used in the switches are 
error detection and correction hardware to protect against 
memory failure and checksumming of critical data structures 
and portions of code. 

An availability of at least 99 % will be provided by the 
network to any pair of single-homed users that wish to 
communicate with each other. Users will have the capability 
to enhance their availability either by dual access (two 
access lines to the same switching nods) or by dual-homing 
(a single access line to two switching nodes). The latter 
method provides an increased network availability of 99 . 95 % 
and will be used for critical subscribers. 

Originating hosts and terminals can assign traffic 
precedence levels which will then be used by the swirching 
nodes and mini-TACs as a criterion in resource allocation. 
The switching nodes provide four levels of precedence, 
preemption of lower precedence connections, non-blocking of 
host input and reservation of buffers and other traffic 
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related data structures. The mini-lAC provides four levels 
of precedence, preemption of input T3P segments and reserva- 
tion of input buffers. Category I (Flash and Flash Override) 
traffic has the highest precedence level and will be 
processed in a non-blocking mode exclusive of all other 
traffic modes and volumes. 

A number of features are provided by DDM to ensure its 
survivability. All DON hardware will have HEMP protection 
in the form of EM shielding, line isolation and surge 
arresting protection. Uninterruptible power supplies will be 
provided to those selected sites having no backup power. To 
facilitate system reconstitution, there will be five mobile 
reconstitution nodes equipped with MC capabilities. DON 
utilizes a dynamically adaptive routing algorithm to auto- 
matically route traffic around congested, damaged or 
destroyed switches and trunks so the system can continue to 
function. There is also a dense trunking grid to provide 
redundancy at all possible points in the network. 

B. SECURITY AHD PRIVACY MEASURES 

“I • Lisii Encrypt ion 

The K3-8U crypto device is used on all backbone 
trunks, on all access lines to classified hosts and 
mini-TACs, and on access lines to sites that act as MCs for 
the unclassified community. The link encryption provides 
full period traffic flow security protection by concealing 
traffic patterns of interswitch traffic, and by concealing 
subnet monitoring reports, which could reveal traffic anal- 
ysis information. It will also protect MC-switch control 
traffic from disclosure. Traffic which is sent from one 
remote host to another remote host is encrypted first by rhe 
Internet Private Line Interface (IPLI) and again by the 
KG-84 (see Figure B.1). 
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Figure B.1 Bnd-to-End Encryption. 
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2. Sec u r it y Sana rati on 

All DDN subscribsrs will operate at a specified 
system high security level. Separation of subscribers at 
different levels is provided by the use of IPLIs, Thus there 
will be at least on IPLI !cey for eaoh different system high 
level, and, at minimum, one such logical subnet for each 
security level. The IP and subnet headers must be in the 
clear for packet processing within the switch, yet they 
provide information about subscriber traffic patterns and 
traffic analysis information is classified secret.. This 
problem is handled by link encryption of subscriber access 
lines and by ensuring that all switching nodes are TEMPEST 
enclosed and in secure military facilities. To prevent 
misdelivery of traffic statistics by the subnet, each MC and 
the "fake" host in each switch that communicates with the MC 
will be members of a logical subnet that includes only these 
members. The requests from the .MC that trigger collection 
and reporting of traffic statistics will be protected using 
a cryptographic authentication protocol. 

3- Seoarati^ of Communities of Interest 

Communities of interest are subscriber groups which 
1) present an acceptable level of risk to each other and 2) 
require a high level of interoperability. Separation of 
communities of interest is accomplisied through the creation 
of logical subnets by cryptographic means, by software 
control, or both. For unclassified subscribers, the switches 
provide the ability to define logical subnets which confine 
traffic flow only to the memoers of that logical subnet. 
These logical subnets are established by the SMC, Currently 
the switches allcw for up to 16 suca subnets, but this can 
be easily increased to 32 or 6'-* , 
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Rigorous separation for classified usee communities 
is provided by IPLIs. As mentioned earlier, there will be 
at least one IPLI subnet (collection of like-keyed IPLIs) 
for each security level. At this time, a community of 
interest is limited by policy to 128 subscribers. 

Access Control 

Access control to subscribers facilities is the 
responsibility of the subscribers taemselves. The network 
will assure, based on a number of special mechanisms, that 
the access of one subscriber to. another is controlled with 
respect to authorized security level and community of 
interest. Network facilities do not /erify, however, that an 
individual user (person or process) attempting to access a 
subscriber has valid access rights to that subscriber. 
Access control to mini-TAIs is provided by physical access 
control measures, as mini-TAC access is only available 
through hardwire lines. 

SSaulSiSiStS 



All personnel with access to switches must be 
cleared to secret level due to the traffic analysis poten- 
tial. This clearance level also applies to all personnel at 
the SMCs and RMCs. Personnel manning a MC for a secure 
subnet must be cleared to the level of the subnet subscri- 
bers, allowing personnel access to the corresponding IPLIs. 
Crypto technicians will be needed for keying the IPLIs for 
each community and for link KGs. The keying material for 
each IPLI community is available only at the IPLI sites. The 
keying material for the link KGs is available on a pairwise 
basis at the switch sites based on switch connectivity. 
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C. HAJOR HARDWARE ELEMENFS 



"I • Swi^hi Node 

The switching nods is a BBIT C/30 packet switching 
processor in a TEMPEST/HEHP package. The C/30 hardware is a 
multi-board, microprogrammed minicomputer with 64K words of 
Random Access Memory (RAM) . It supports a full range of 
synchronous and asynchronous I/O interfaces. The C/30 soft- 
ware is the ARPANET Interface Message Processor (IMP) 
program. IMP software can be loaded locally (from a 
cassette) or by a downline load under MC control. The soft- 
ware provides four major functional capabilities: 1) Tandem 

(store and forward) traffic processing 2) Host access and 
end-to end traffic processing, using a variety of hose 
access protocols 3) Routing via a dynamic, adaptive 

distributed routing algorithm that measures actual packet 
delays and routes individual packets along the least delay 
path 4) Monitoring and control services. 

2* Pr i v at e Line 

The IPLI is a security device, currently under 
development, which supports the D3D standard IP protocol and 
provides end-to-end encryption. IPLI is composed of three 
functional units: a KG 34 cryptographic device and two 

MC68000 based packet processors (one on the red side and one 
on the black side of the KG 84) . Two hardware iaterfaces are 
provided on each side of the IPLI. Initially used for backup 
purposes, they will later provide for dual-homing 

Topologies. 

The software in each processor will be based on the 
CMOS operating system being used for a variety of packet- 
switching applications. It will have the basic functions 
necessary for the DOD standard internet environment and for 
monitoring and ccntrol. TCP and other protocols which exist 
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above the IMP can be supported sines the IPLI has no knowl- 
edge of the TCP and packet processing occurring at the 
Internet Protocol lower level. 

3, Mini-TAC 



A mini-TAC is a terminal access device that allows a 
cluster of up to 16 synchronous and asynchronous terminals 
to access the network. It is logically equivalent to a 
network host, particularly in that it uses the same host- 
host protocols. A mini-TAC will be constructed around a 
Motorola MC68000 microprocessor with memory, 15 synchronous 
or asynchronous terminal ports and nultiple network inter- 
face ports. The mini-TAC will meet TEMPEST and HEMP 
requirements. 

The mini-TAC software allows terminal users to 
establish connections between their terminals and an arbi- 
trary host on the network. The software will multiplex all 
of the terminal-host connections over a single TAC-IM? 
access line. Mini-TACs will communicate with other network 
hosts using the DOD standard TCP and IP. The Telnet protocol 
will be used to provide terminal level support. 

The mini-TACs will be designed for unattended opera- 
tion and will require no dedicated personnel. All control 
functions and hardware and software fault diagnosis can be 
done remotely from the network Monitoring Centers. 
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APPENDIX C 

THANSHISSIDH CONTROL PROTOCOL 



This appendix presents a simple description of the 
Transmission Control Protocol. The information provided was 
obtained from the DARPA Transmission Control Protocol docu- 
ment of January 1980 [Ref. 23]. 

A. GENERAL 

The Transmission Control Protocol (TCP) is intended for 
use as a highly reliable standard for the transmission and 
reception of messages between host computers in a packet 
switched computer communications environment. This internet- 
work environment consists of hosts connected to networks 
which are in turn interconnected via gateways. 

TCP is a connection-oriented, end-to-end reliable 
protocol designed to fit into a layered hierarchy of proto- 
cols which support multi network applications. It provides 
for reliable in ter- process communication between pairs of 
processes in host computers attached to distinct but inter- 
connected computer communications networks. The TCP fits 
into a layered protocol architecture just above a basic 
Internet Protocol (IP) which provides a way for the TCP to 
send and receive blocks of data, called datagrams, through 
multiple networks and interconnecting gateways. (See Figure 
C.1) . 

B. BASIC FUNCTIONS 

Since the primary purpose of TCP is to provide reliable, 
securable and logical circu it or connection service between 
pairs of processes the following facilities are required: 
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Figure C, 1 Protocol Layering. 

• l§.sic D a;^ T rans f sr 

By packaging some number of ncters into segments for 
transmission through the internet system, the 13? is able to 
transfer a continuous stream of octets in each direction 
between its users. The decision to block or forward data is 
made by the T3P at its own convenience. Users are also 
allowed to submit records, called letters, for transmission. 
In this case, the TCPs will forward and deliver data up to 
the record boundary (end-o f-lettec) that was specified by 
the sending user. 

Pe l l ability 

The TCP must be able ro recover whan data is 
damaged, lost, duplicated or delivered out of order by the 
internet communications system. To accomplish this, each 
octet transmitted is assigned a sequence number, and a posi- 
rive acknowledgement (ACK) is required from the receiving 
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TC? within a specified time interval. If tbe ACK is not 
rereived, data is retransmitted. 

The sequence numbers are used by the receiver to 
correctly order segments arriving out of order and to elimi- 
nate duplicates. A cheo ksum is added to each segment 
transmitted to deal with damage occurrance. This checksum is 
verified at receiving end and all damaged segments are 
discarded. If the internet system doss not become completely 
partitioned, properly functioning ICPs will be able to 
recover from internet communication system errors. 

3 • F low Control 

The receiver can govern the amount of data sent by 
the sender by returning a '•window'' with every ACK indicating 
a range of acceptable sequence numbers beyond that of the 
last successfully received segment. In stream mode, the 
window indicates the number of allowable octets the sender 
may transmit before further permission must be obtained. In 
record mode, the window tells the allowed amount of buffer 
space the sender may consume. 

^ • Mul tipl e xinq 

The TCP provides a set of addresses or ports within 
each host to permit many processes within that host to use 
TCP ccmmunicati on facilities simultaneously. These are 
concatenated with the network and host addresses from the 
internet communication layer and fora a socket. Each connec- 
tion is uniquely identified by a pair of sockets, so one 
socket may be used in multiple connections. 

The connection of ports to processes is indepen- 
dently handled by each host, howe/er it proves useful to 
attach frequently used processes to fixed sockets and make 
these addresses known to users. These services can then be 
accessed more easily. 
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5* Co nnect i ons 



TCPs are required by both the reliability and flow 
control mechanisms to initialize and maintain certain status 
information for each data stream. rhe combination of this 
information, which includes sockets, sequence numbers and 
window sizes, is called a connection. The pair of sockets 
that identifies its two sides uniquely specifies a 
con necticn. 

If two processes wish to cammunicate, their TCPs 
must first establish a oonnection. This is accomplished 
throuqh the initialization of the status information on each 
side. When the communication is complete, the connection is 
terminated or closed to free the resources for other users. 
Since these connections must be established between hosts 
over a somewhat unreliable internet communication system, a 
handshake mechanism with clock-based sequence numbers is 
used to avoid erroneous ini tializatin n of connections. 

Preceden ce and Securi^ 

The users of TCP may indicate the security and 
precedence of their communication. Since not all TCP 
modules will necessarily function in a multilevel secure 
environment, some may be limited to unclassified use only 
and others may operate at only one security level. 

Provision is made for default values to be used when these 
features are not needed. 

C. MODEL OF OPEHATION 

Processes transmit data by calling on the TCP and 
passinq buffers of data as arguments. The TCP packages the 
data from these buffers into segments and calls on the 
internet module to transmit each segment to the destination 
TCP. The receiving TCP places the data from a segment into 
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tha receiving user's buffer and notifies the receiving user. 
Control information is included in the segments used by the 
TCPs to insure reliable ordered data transmission. 

Each TCP has an internet protocol module associated with 
it to provide an interface to the local network. This 
internet module packages TCP segments inside internet data- 
grams and routes these datagrams to a destination internet 
module or intermediate gateway. To transmit the datagram 
through the local network, it is embedded in a local network 
packet. The packet switches may perform further packaging, 
fragmentation or other operations to achieve the delivery of 
the local packet to the destination internet module. 

At a gateway between networks, the internet datagram is 
"unwrapped” from its local packet aid examined to determine 
through which network the internet datagram will travel 
next. The internet datagram is then "rewrapped” in a local 
packet suitable to the next network and routed to the next 
gateway, or to the final destination. 

A gateway can break up an internet datagram into smaller 
internet datagram fragments if needed to allow transmission 
through the next network. To accomplish this, the gateway 
produces a set of internet datagrams, each of which contains 
a fragment of the original. These fragments may be broken 
down again at intermediate gateways. The fragment format is 
designed so that the destination internet module can reas- 
semble these fragments into internet datagrams. 
destination module unwraps the segment from the datagram 
(after fragments have been reassembled, if necessary) and 
passes it to the destination TCP. 

It should be noted that the mechanisms of TCP do not 
preclude implementation of the TCP in a front-end processor, 
however, in such a case a hcst-to-f ront-end protocol must 
provide the functionality to support the type of TCP-user 
interface required. 
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